An information handling system (IHS) may include multiple processors or processor cores for processing, handling, communicating or otherwise manipulating information. A multitasking IHS is an IHS with an operating system (OS) that executes multiple processes simultaneously. The processor(s), processor cores and operating system (OS) cooperate to provide a multitasking IHS environment that manages several individual software application programs and their attendant processes. Some software applications or processes in such applications may require extensive IHS resources and consequently take a long time to execute. For example, some software processes require several minutes, hours or even days to execute in some cases. Processes that require extensive IHS resources and time may run more efficiently if the OS allows the process software to run without an IHS user's attention. The user then retrieves the process data results at a later time when the software process completes.
System users, including programmers and other IHS users, initiate processes to run within the IHS. Processes, namely portions of software applications, may execute in foreground or background modes within the IHS under operating system (OS) control. In multitasking systems, one of many processes runs in the foreground as a foreground process, while one or more remaining processes run in the background as background processes. Foreground processes run interactively with the system user by accepting input from keyboard, mouse, or other input devices. Background processes run in the background typically without user intervention until completion. The OS typically directs the output of processes, such as process data results, running in foreground mode to a terminal or other output device for viewing or use by the system user. The OS associates foreground processes with a particular system user. In true multitasking IHS environments, multiple system users can log into the IHS at any given time. Thus, the OS may manage multiple foreground processes at the same time. Each process then running within the IHS, includes a respective process ID that associates the process with the particular system user who initiates the process.
Background processes typically have a lower priority than foreground processes. OS software sets the background process to the lower priority to ensure that no interference occurs with the higher priority interactive foreground processes. For example, some word processors may print files in the background, enabling the system user to continue editing a word processing document while files print. Typically this background process is known as “print spooling”. Background processes run without the need for interactive control or user intervention. Background processes are suitable for processes that require significant processor time without the need for system user interaction. In background process tasks, results typically output to a processor system file in a storage device such as a hard drive, compact disk (CD), or other storage media that the system user can access at a later time.
The system user may initiate a process in the foreground and then desire to move the same process to the background at a later time. For example, the system user may need to initiate a new foreground process and let the current process continue running. Another reason to move the process from the foreground mode to the background mode is the situation where the process takes more time to complete than the system user originally expects. Thus the system user may wish to move to a new location or monitor the process at a later time.
System users who run processes in background mode can include an operating system (OS) level command such as the “nohup” (no hang-up) command when they initiate or begin the processing of a process or software program containing a process. The user may submit this OS command as a request at the time the program with the process initiates. This approach is particularly useful in instances where the user knows in advance that execution of the process will take a long time. System users may set the proper nohup OS command at the time of process initiation to prevent future actions such as “logging-out” from affecting the process. System users can return to the process for results when convenient at a later time. However, the nohup command typically requires the user to input the command when the process initiates.
What is needed is an apparatus and methodology that addresses the problems of executing software processes within a complex multitasking IHS with unpredictable process time constraints, namely those where the user does not know in advance how long execution of a software process will take.